The bug

ResourceTemplate.matches() builds its regex by naive string replacement:

pattern = self.uri_template.replace("{", "(?P<").replace("}", ">[^/]+)")
match = re.fullmatch(pattern, uri)

Only the {/} delimiters are transformed — the literal (non-parameter) segments of the URI template are spliced into the regex verbatim, with no re.escape(). Any regex metacharacter in a literal segment (., +, ?, *, (, ), [, |, ...) is therefore interpreted as regex syntax instead of being matched literally.

Step-by-step proof

Take the template test://a.b/{x}:

1. The .replace() calls produce the pattern test://a.b/(?P<x>[^/]+).
2. The . in a.b is an unescaped regex wildcard, so it matches any character, not just a literal dot.
3. re.fullmatch('test://a.b/(?P<x>[^/]+)', 'test://aXb/foo') succeeds — . consumes X.
4. matches() returns {'x': 'foo'}, and the URI is dispatched to a handler whose template it does not actually match.

Two worse variants were verified empirically:

• Semantics change: template test://a+b/{x} compiles a+ as "one or more a", so it matches test://ab/foo and test://aab/foo — and, depending on the surrounding literal, can fail to match its own literal form test://a+b/foo.
• Crash: a template containing a bare ( in a literal segment (e.g. test://a(b/{x}) raises re.error: missing ), unterminated subpattern at match time, turning a registration-time template typo into a runtime exception on every read_resource lookup.

Why nothing prevents it

There is no escaping or validation anywhere on this path: ResourceTemplate.from_function stores uri_template as a plain string, and matches() is the only place it is interpreted. The wire path's pydantic AnyUrl normalization does not help here — it normalizes the incoming URI, not the server-side template, and dots/plus signs are perfectly legal URL characters that survive normalization.

Relation to this PR

This is squarely pre-existing: the naive .replace() construction on line 88 is untouched by this PR, which only switched the adjacent re.match(f"^{pattern}$", uri) to re.fullmatch(pattern, uri) — a strictly tighter change that neither introduces nor worsens the escaping gap. It's worth noting only because the PR modifies this exact function and fixes the same bug class (overly-permissive template matching), so a follow-up here would be a natural companion.

How to fix

Split the template on {param} boundaries and escape the literal chunks before reassembling, e.g.:

parts = re.split(r"\{(\w+)\}", self.uri_template)
pattern = "".join(
    f"(?P<{part}>[^/]+)" if i % 2 else re.escape(part)
    for i, part in enumerate(parts)
)
match = re.fullmatch(pattern, uri)

This keeps the existing [^/]+ parameter semantics while making literal segments match literally, and eliminates the re.error crash for templates containing regex metacharacters.